\chapter{First Milestone}
The major goal of the first milestone is to implement a first runnable implementation. This implementation has not to be complete, but should show the intention where the project should go. But before any implementation work is done, some design issues has to be solved. Beside that elementary decisions have to be made, e.g. which WebSocket provider should be used. 
% introductional words
% what is the intention of this chapter
% * design issues
% * elementary decisions
% * conceptional decisions
% * implementing a first prototype

\section{Conceptional Decisions}
The previous chapter demonstrated two methods how to scan for annotations. Because this project is intended for Spring users, the BeanPostProcessor method is chosen.  Working with the BeanPostProcesspr implies that the annotation scanning and the following export via websockets can only be applied to Spring Beans. Chosing other objects to be exported normally leads to broken designs. 
\\\\Scanning the annotation and the creation of the services on compiler level(e.g. with a compiler plugin) would have complicated things enormously. Because on compiler level only classes are aviable, a bytecode engineering library had to be used. Personally, a bytecode engineering library is more vodoo than injecting or creating anonymous proxies on runtime. 

\subsection{Provider for WebSockets}
Because out in the wild exist multiple WebSocket implementation, not an own one was created. There are many implementations of the WebSocket protocol also for different plattforms e.g. .NET. It seems that the community is very excited about this new HTML5 feature. Googling for a WebSocket implementation Java, the following two candidates have been considered as usable:
\begin{itemize}
  \item Netty WebSocket example\cite{nettyWebSocket}
  \item xLightWeb WebSocket implementation\cite{xlightweb}
\end{itemize} 
During the creation of the bachelor thesis xLightWeb is known, this implementation was chosen as provider. But when in the future another provider is preferred, it should be no problem to make the provider replacable.

\subsection{Chosing the communication protocol}
Basicly WebSocket has no definitions which communication protocol is used for the communication between server and client. So it's up to the developr or architect to decide which communication protocol can be used. One possibility is to define it's own communication protocol or reuse an already defined one.
\\\\There are some typical requirements for a communication protocol:
\begin{itemize}
  \item be easy to read for humans
  \item be easy to read for maschines
  \item be easy to write for humans
  \item be easy to write for maschines
  \item be realiable
  \item be generic 
\end{itemize}
After reading theese requirements it should be clear, that not all of theese requirements can be fulfilled. Basicly, the developer has to decide what is the most important thing for him. Beside that, it's also possible to choose a balanced protocol; none of the above menetioned requirements is 100\% fulfilled, but none of the requirements is completly ignored. One of those protocol is JSON-RPC\cite{jsonrpc} and has been chosen as communication protocol. The most interesting thing about JSON-RPC that a JSON-RPC package is also a valid JSON string, so it can be easily be serialized and deserialized.
\\\\The JSON-RPC protocol only knows a request and a response; only theese two objects are defined in the protocol. A request contains the method name, parameters of this method and a unique id of the reuqest. 
\lstset{emph={int,for},
stringstyle=\tt,
basicstyle=\tt,
numbers=left}
\begin{lstlisting}[frame=trb,caption={Example of a JSON-RPC request}, captionpos=b]{}

\end{lstlisting}
\subsection{Implementing server side methods}

\subsection{Project structure}




\subsection{Implementing a client}
\section{Summary}
\subsection{What works}
What works:
\begin{itemize}
  \item Annotation scanning for client and server
  \item Client to server method calling without return values
  \item Server to client broadcasting without return values
  \item Parameter handling in method calls
\end{itemize}
\subsection{What has to be done}
What has still to be done:
\begin{itemize}
  \item Thread safe handling of return values
  \item Connection specific method calls
  \item Currently the communication protocol is not replacable, but this should be an easy task
\end{itemize}